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Executive  Summary 


This  report  was  prepared  to  address  the  issue  of  where  software  should  reside  in  the  Work  Breakdown 
Structure  (WBS)  for  a  space  system.  The  report  first  provides  some  background  on  Integrated  Prod¬ 
uct  and  Process  Development  (IPPD)  and  the  standard  product-oriented  WBS  structure  established 
for  space  systems  by  MIL-HDBK-881 A  [DOD1].  The  report  then  describes  the  various  software 
activities  that  must  be  performed  for  space  system  development  and  provides  recommendations  as  to 
where  these  activities  belong  in  this  standard  product-oriented  space  system  WBS  structure.  While 
development  activities  for  individual  software  items  (e.g.,  software  requirements  definition,  design, 
implementation,  and  test)  will  reside  at  lower  WBS  levels  beneath  the  WBS  elements  for  the  products 
in  which  the  software  items  reside,  there  are  a  large  number  of  very  important  cross-product  software 
activities  that  must  be  accomplished  on  our  complex,  software-intensive  space  systems.  This  report 
strongly  recommends  that  these  activities  belong  in  WBS  Software  Common  Elements  at  Level  2  and 
below.  The  cross-product  activities  of  the  Level  2  WBS  Software  Common  Element,  in  particular, 
are  critically  important  for  program  success,  and  the  report  provides  an  enumeration  of  these  activi¬ 
ties.  The  report  also  includes  discussions  of  (1 )  the  relationship  between  the  Software  and  Systems 
Engineering,  Integration  and  Test  WBS  common  elements;  (2)  software  WBS  elements  for  the  early 
acquisition  phases;  and  (3)  the  relationship  between  WBS  elements  and  organizational  structures. 

The  report  concludes  by  recommending  that  the  critically  important  activities  of  the  Level  2  WBS 
Software  Common  Element  be  performed  by  a  Level  2  Software  Systems  Engineering,  Integration 
and  Test  Integrated  Product  Team  (IPT)  specifically  established  for  that  purpose. 
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1.  Background 


This  report  addresses  the  question  of  where  software  should  appear  in  the  Work  Breakdown  Structure 
(WBS)  for  a  space  system.  This  question  was  raised  by  several  different  programs  in  the  early  stages 
of  space  system  acquisitions.  In  particular,  the  question  that  was  asked  was  whether  or  not  software 
should  be  placed  at  Level  2  in  the  WBS  for  a  space  system. 

The  correct  answer  to  where  software  should  go  in  a  space  system  WBS  is  more  complicated  than  a 
single  number.  The  Work  Breakdown  Structure  provides  a  mechanism  for  enumerating  the  work 
being  performed  on  a  program,  both  for  the  contractor  team  and  for  the  government  program  office. 
Software,  in  fact,  belongs  at  a  number  of  places  in  the  WBS,  some  higher  than  others.  This  is  due  to 
the  diversity  of  the  software  tasks  that  must  be  performed  as  well  as  to  the  position  of  software  in  the 
space  system  product  structure.  The  following  sections  describe  the  recommended  positioning  of  the 
various  software  tasks  in  a  space  system  WBS  and  provide  rationale  for  their  location. 


2.  Integrated  Product  and  Process  Development  (IPPD) 
versus  Functional  Organizational  WBS  Structures 


In  the  early  1990s,  the  Air  Force  changed  from  using  a  functional  organization  for  program  manage¬ 
ment  to  using  Integrated  Product  and  Process  Development  (IPPD).  Under  the  earlier  functional 
organizational  structure,  managers  were  responsible  for  a  particular  function,  such  as  systems  engi¬ 
neering,  hardware  development,  software  development,  integration  and  test,  or  logistics  support. 
Under  the  new  IPPD  paradigm,  however,  programs  are  organized  by  product  into  Integrated  Product 
Teams  (IPTs),  and  the  manager  of  each  IPT  is  responsible  for  developing  that  IPT’s  product  to  meet 
its  allocated  requirements  within  its  allocated  cost  and  schedule.  All  aspects  of  the  product  develop¬ 
ment  are  intended  to  be  integrated  in  this  management  structure,  including  product-level  systems 
engineering;  hardware  and  software  development;  specialty  engineering;  integration  and  test;  and 
verification/qualification.  In  addition,  product  development  includes  developing  the  processes  and 
any  associated  hardware  and  software  needed  for  the  development,  verification/qualification,  manu¬ 
facturing,  deployment,  operations,  support,  training,  and  disposal  of  the  product.  The  IPT  product 
development  manager  is  responsible  for  all  costs  associated  with  all  of  these  aspects  of  the  product. 

From  a  WBS  perspective,  in  a  functional  organizational  structure.  Level  2  of  the  WBS  would  match 
the  designated  functions.  Thus,  there  were  Level  2  entries  in  the  WBS  that  contained  all  work  for 
each  function,  so  all  aspects  of  software  development  were  placed  under  a  single  Level  2  WBS  ele¬ 
ment.  With  the  transition  to  IPPD,  Level  2  of  the  WBS  structure  became  product  oriented  rather  than 
function  oriented. 
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3.  The  Product-Oriented  Standard  Space  System  WBS 


For  many  years  the  Department  of  Defense  has  had  a  handbook  for  defining  the  WBS  for  acquisi¬ 
tions.  A  new  version  of  this  handbook  has  recently  been  published  (MIL-HDBK-881  A,  “Work 
Breakdown  Structures  for  Defense  Materiel  Items,”  30  July  2005  [DOD1  ]).  This  handbook  is  man¬ 
datory  for  all  programs  that  fall  under  DoD  5000.2  [DOD2],  National  Security  Space  Acquisition 
Policy  NSS  03-01  [USECAF],  however,  also  requires  the  use  of  this  handbook  for  defining  the  WBS 
structure  for  all  National  Security  Space  (NSS)  programs  subject  to  NSS  03-01 .  In  paragraph  AP3.4, 
NSS  03-01  states:  “Generally,  the  NSS  program  office  shall  follow  the  standard  product-oriented 
WBS  structure  specified  in  MIL-HDBK-881.”  The  WBS  structure  is  required  to  be  documented  in 
the  program’s  Cost  and  Software  Reporting  Plan,  which  must  be  approved  by  the  chairman  of  the 
Office  of  the  Secretary  of  Defense  (OSD)  Cost  Analysis  Improvement  Group  (CAIG).  Thus,  any 
deviation  from  the  standard  product-oriented  WBS  structure  must  be  approved  at  the  OSD  level  for 
NSS  programs  subject  to  NSS  03-01 . 

The  standard  product-oriented  WBS  structure  for  space  systems  is  found  in  Appendix  F  of  MIL- 
HDBK-88 1 A  and  provided  in  the  Appendix  of  this  report.  The  first  two  levels  of  this  WBS  structure 
are  summarized  in  Table  1. 

The  table  in  the  Appendix  has  been  enhanced  to  illustrate  where  space  and  ground  operational  and 
other  supporting  software  products  would  reside  in  this  standard  space  system  WBS  structure.1  As 
shown  in  the  table  in  the  Appendix,  the  software  development  activities  reside  in  multiple  Level  4 
WBS  elements  within  the  product  in  which  the  software  resides.  Each  of  these  software  WBS  ele¬ 
ments  at  Level  4  includes  all  of  the  work  involved  in  developing  that  particular  software  item  [i.e., 
software  requirements  definition,  software  architectural  design,  software  detailed  design,  software 
implementation  and  unit  testing,  software  unit  integration  and  testing,  software  qualification  testing, 
software  specialty  engineering  (e.g.,  information  assurance,  safety,  human  systems  integration,  reli¬ 
ability/maintainability/availability)],  plus  all  of  the  associated  software  project  management  activities 
(e.g.,  planning,  tracking  and  controlling;  configuration  management;  joint  management  reviews)  and 
quality  enhancement  activities  (e.g.,  peer  reviews,  product  evaluations,  joint  technical  reviews)  for 
that  software  item. 

Table  1 .  Levels  1  and  2  of  the  Standard  Product-Oriented  WBS  Structure  for  Space  Systems 

Level  1  Level  2 

Space  System 

SEIT/PM2  and  Other  Common  Elements 

Space  Vehicle  (1 _ n  as  required) 

Ground  (1...n  as  required) 

Launch  Vehicle 


1  Other  supporting  software  includes  software  used  in  satisfying,  verifying,  or  validating  requirements  or  used  in 
performing  or  supporting  operations  or  maintenance.  Examples  include  simulators,  training  software,  testbed  software, 
and  automated  test  software. 

2  SEIT  =  Systems  Engineering,  Integration  and  Test;  PM  =  Program  Management. 
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The  “Common  Elements”  in  the  standard  product-oriented  WBS  structure,  however,  are  extremely 
important.  MIL-HDBK-88 1 A  states  the  following  (paragraph  F.3. 1 ,  p.  76): 


“Common  WBS  Elements  must  include,  as  a  minimum,  systems  engineering,  integration  and 
test,  and  program  management  (SE1T/PM).  Common  elements  are  found  throughout  all  lev¬ 
els  of  a  WBS  and  are  located  one  WBS  level  below  the  product  oriented  WBS  they  support 
(e.g.,  structures  and  mechanisms  SEIT/PM  would  be  captured  at  Level  5  below  the  Structures 
and  Mechanisms  Subsystem).  Other  common  elements,  such  as  training  or  data,  as  applic¬ 
able,  may  be  included  here.  The  table  above  [i.e.,  the  table  in  Appendix  F  of  MIL-HDBK- 
88  1  A]  is  not  complete  without  the  application  of  common  elements [emphasis  in  italics 
added] 

The  need  for  Software  Common  Elements  in  the  standard  product-oriented  space  system  WBS  is 

described  in  the  following  section. 
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4.  Software  Common  Element  Activities 


In  addition  to  the  software  development  activities  described  above  for  the  space,  ground,  and  sup¬ 
porting  software  products,  there  are  a  large  number  of  important  software  activities  that  transcend  the 
software  product  boundaries.  These  “cross-product”  activities  belong  under  the  category  of  “Com¬ 
mon  Elements”  shown  in  Table  1  at  Level  2  and  in  the  table  in  the  Appendix  at  Levels  2,  3,  and  4. 

There  are  always  important  software  activities  that  apply  across  all  of  the  software  products  on  the 
program.  This  report  strongly  recommends  that  these  activities  be  included  in  a  Level  2  WBS  Com¬ 
mon  Element  for  software.  An  appropriate  name  for  this  Software  Common  Element  is  “Software 
Systems  Engineering,  Integration  and  Test.”  Examples  of  the  important  activities  included  in  this 
Level  2  WBS  Software  Common  Element  are  as  follows: 

•  Software  Planning,  Tracking  and  Control 

o  Conducting  a  cross-program  Software  Integrated  Product  Team  (IPT)  to 
engage  all  software  product  organizations  in  the  work  of  the  Software  Com¬ 
mon  Element 

o  Preparing  and  maintaining  an  integrated  Software  Development  Plan  (SDP) 
for  all  software  development  and  maintenance  activities  across  the  program 

o  Providing  software  engineering  management  and  control  to  enforce  adher¬ 
ence  to  the  SDP  and  other  compliance  documents 

o  Conducting  Capability  Maturity  Model®  IntegrationSM  (CMMI®)  process 
maturity  appraisals  and  working  with  the  software  product  organizations  to 
improve  their  processes3 

o  Defining,  collecting,  analyzing  and  reporting  uniform  software  metrics 
across  the  program,  and  ensuring  corrective  action  is  taken  where  indicated 
by  the  metrics 

o  Participating  in  joint  management  meetings  (e.g.,  monthly  Program  Manage¬ 
ment  Reviews,  monthly  software  management  reviews) 

o  Identifying  and  resolving  cross-product  software  issues 

o  Identifying  software-related  risks  and  interfacing  with  the  program  risk  man¬ 
agement  process  for  risk  handling  and  mitigation 

o  Developing  and  maintaining  integrated  software  schedules  as  part  of  the  Inte¬ 
grated  Master  Schedule  (IMS),  including  software  build  schedules 


3  Capability  Maturity  Model  and  CM  MI  are  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon 
University.  Capability  Maturity  Model  Integration  is  a  Service  Mark  (SM)  of  Carnegie  Mellon  University. 
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o  Participating  with  the  software  product  teams  to  define  the  software  build 
contents  (requirements,  capabilities)  to  ensure  integration  and  delivery  needs 
are  met  across  the  program 

o  Implementing  an  integrated  closed-loop  corrective  action  process  across  the 
software  products 

o  Implementing  and  maintaining  a  uniform  software  deficiency/change  report¬ 
ing  system  across  the  software  products 

o  Analyzing  software  deficiency  reports  across  the  software  products  to  iden¬ 
tify  systemic  problems  and  root  causes  and  to  initiate  corrective  actions 

o  Apprising  program  management  of  the  status  of  the  software  development 
effort  across  the  program;  elevating  issues  that  cannot  be  resolved  by  the 
Software  1PT  to  program  management  for  resolution 

•  Software-Related  Systems  Engineering,  Integration  and  Test 

o  Leading  the  specification  of  software-related  requirements  for  the  system  and 
segments 

o  Participating  in  the  allocation  of  requirements  from  system  to  segment  to  ele¬ 
ment/subsystem  to  software  item,  including  the  allocation  of  software  spe¬ 
cialty  engineering  requirements  (e.g.,  safety,  information  assurance,  reliabil¬ 
ity/maintainability/availability,  human  system  integration) 

o  Participating  in  the  space  and  ground  segment  level  designs,  including 
space/ground  and  hardware/software  trades 

o  Leading  the  development  of  the  overall  (cross-product)  processing  hardware 
and  software  architecture 

o  Participating  in  the  definition  of  external  and  inter-segment  interfaces  and  the 
resolution  of  external  and  inter-segment  interface  issues  involving  software 

o  Leading  the  definition  of  software-to-software  and  software-to-hardware 
interfaces  within  and  among  the  space  and  ground  elements/subsystems  and 
software  and  hardware  items,  and  resolving  related  interface  issues 

o  Evaluating  software  requirements  and  software  architectures  developed  for 
the  software  items  by  the  software  product  teams  to  ensure  that  the  software 
level  requirements  properly  implement  their  allocated  higher  level  require¬ 
ments  and  that  the  individual  software  architectures  are  consistent  with  the 
overall  processing  hardware  and  software  architecture 

o  Leading  the  identification  and  resolution  of  margin  issues  for  computer 
resource  utilization 

o  Defining,  collecting,  analyzing  and  reporting  uniform  software-related  Tech¬ 
nical  Performance  Measures  (TPMs)  across  the  program,  and  taking  correc¬ 
tive  action  where  indicated  by  the  TPMs 

o  Participating  in  integration  testing  of  hardware  and  software  items,  subsys¬ 
tems/elements,  segments  and  the  system,  including  identifying  and  docu¬ 
menting  software-related  deficiencies 
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o  Participating  in  subsystem/element,  segment  and  system  qualification  testing, 
including  evaluating  software-related  requirements  verification  status  and 
documenting  software-related  deficiencies 

o  Monitoring  software  build  integration  testing  of  the  software  products, 
including  participating  in  software  deficiency  identification  and 
documentation 

o  Monitoring  software  qualification  testing  of  the  software  products,  including 
participating  in  evaluating  software-related  requirements  verification  status 
and  documenting  deficiencies 

o  Ensuring  that  all  software  items  meet  their  allocated  software  specialty  engi¬ 
neering  requirements  and  that  all  cross-product  software  specialty  engineer¬ 
ing  requirements  are  met  (e.g.,  integrated  fault  detection  and  isolation; 
human  systems  integration;  information  assurance) 

o  Implementing,  populating,  validating  and  maintaining  the  operational  data¬ 
bases  (e.g.,  flight  constants  database,  ground  operational  databases)  and 
related  software  required  to  support  integration,  verification,  launch  prepara¬ 
tion  and  operations 

o  Providing  software-related  support  to  operational  testing  (e.g.,  Initial  Opera¬ 
tional  Test  and  Evaluation  (IOT&E)  by  the  Air  Force  Operational  Test  and 
Evaluation  Center  (AFOTEC)) 

o  Providing  software-related  support  to  launch  preparation  and  operations 

•  Software-Related  Technical  Reviews  and  Audits 

o  Participating  in  system,  segment  and  element/subsystem  level  requirements 
reviews,  design  reviews  and  test  readiness  reviews  for  software-related  topics 
[e.g.,  System  Requirements  Review  (SRR),  System  Design  Review  (SDR), 
Preliminary  Design  Review  (PDR),  Critical  Design  Review  (CDR),  Test 
Readiness  Review  (TRR)] 

o  Attending  and  evaluating  software  level  joint  technical  reviews  and  meetings 
(e.g.,  software  PDRs,  CDRs  and  TRRs;  build  architecture,  design  and  test 
readiness  reviews)  held  by  the  software  product  organizations 

o  Participating  in  peer  reviews  of  development  products  held  by  the  software 
product  organizations 

o  Performing  software  product  evaluations  of  development  products  and 
working  with  the  software  product  organizations  to  resolve  quality  issues 

•  Software  Configuration  Management 

o  Implementing  and  maintaining  a  uniform  software  configuration  manage¬ 
ment  system  across  the  software  products 

o  Participating  on  program  and  software  Configuration  Control  Boards  to  eval¬ 
uate  impacts  of  software-related  changes 

o  Performing  periodic  software  configuration  audits  across  the  program 
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o  Conducting  software  Functional  Configuration  Audits  (FCAs)  and  Physical 
Configuration  Audits  (PCAs) 

•  Software  Quality  Assurance 

o  Performing  software  quality  audits  of  software  processes  and  products  across 
the  program,  and  issuing  non-compliance  reports 

o  Monitoring  software  qualification  testing  for  the  software  products 

o  Maintaining  software  quality  assurance  records 

o  Communicating  quality  issues  to  program  and  software  management 

o  Implementing  a  closed-loop  process  for  tracking  and  resolving  non- 
compliance  issues,  including  elevating  those  issues  when  necessary 


Table  2  contains  the  first  two  levels  of  the  product-oriented  standard  space  system  WBS  with  some  of 
the  typical  Level  2  Common  Elements  for  space  systems  elaborated  and  showing  the  recommended 
position  of  the  Level  2  Software  Systems  Engineering,  Integration,  and  Testing  Common  Element. 
The  table  in  the  Appendix  also  shows  these  common  elements  at  Level  2. 

Cross-product  activities  are  also  possible  for  subsets  of  the  software  products.  Hence,  it  is  possible 
for  Software  Common  Elements  to  exist  at  Levels  3  and  below  in  the  WBS  (see  Appendix).  As  an 
example,  a  Ground  Software  Common  Element  (“Ground  Software  Systems  Engineering,  Integration 
and  Test”)  may  exist  at  Level  3  under  the  Ground  Segment  to  handle  software  activities  that  cross 
ground  software  product  boundaries.  This  would  be  needed,  for  example,  when  the  ground  segment 
has  multiple  software  items,  possibly  being  developed  by  multiple  subcontractors,  that  must  be  inte¬ 
grated  together  to  perform  the  ground  segment  functions  and  meet  the  ground  segment  requirements. 
These  lower  level  Software  Common  Elements  include  activities  such  as  those  listed  above  for  the 
Level  2  Software  Common  Element,  but  only  as  these  activities  apply  to  the  products  within  their 
parent  WBS  element  (e.g.,  the  Ground  Software  Common  Element  would  handle  only  cross-ground 

Table  2  Space  System  WBS  with  Level  2  Common  Elements  Elaborated 

Level  1  Level  2 

Space  System 

Program  Management  (PM) 

Systems  Engineering,  Integration  and  Test  (SEIT) 

Software  Systems  Engineering,  Integration  and  Test 
Training 

Operational  Site  Activation  and  Operations  Support 
Common  and  Peculiar  Support  Equipment 
Initial  Spares  and  Repair  Parts 
Data 

Other  Common  Elements,  as  required 
Space  Vehicle  ( 1 . . .  .n  as  required) 

Ground  (1 . .  n  as  required) 

Launch  Vehicle 
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software  product  activities).  Even  if  lower  level  Software  Common  Elements  exist  in  the  WBS,  the 
Level  2  Software  Common  Element  is  still  necessary  to  handle  software  activities  that  cross  software 
product  boundaries  for  the  entire  program. 
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5.  Relationship  Between  the  SEIT  and  Software  Common  Elements 


In  many  existing  space  system  WBSs,  the  software  cross-product  activities  are  placed  at  Level  3 
under  the  Level  2  SEIT  WBS  element.  While  this  reduces  the  number  of  Level  2  WBS  Common 
Elements,  it  is  not  optimal  for  new  software-intensive  space  systems. 

Older  legacy  space  systems  were  hardware  centric,  with  ground-based  data  processing  and  little 
onboard  software.  Newer  space  systems  have  become  information  centric,  with  all  missions  being 
dependant  upon  large  amounts  of  complex  software,  both  onboard  the  space  vehicle  [105  to  106 
Source  Lines  of  Code  (SLOC)]  and  on  the  ground  (106  to  107  SLOC).  In  addition,  software  develop¬ 
ment  has  become  acknowledged  as  one  of  the  highest  risk  areas  in  these  new  software-intensive  space 
systems.  The  position  of  the  Software  Common  Element  in  the  WBS  must  be  commensurate  with  the 
risk  and  importance  of  software  in  the  space  system.  In  addition,  the  position  of  the  Software  Com¬ 
mon  Element  must  ensure  that  a  budget  is  allocated  to  the  critically  important  software  cross-product 
activities  that  is  sufficient  to  ensure  proper  execution  of  those  activities. 

The  manager  responsible  for  the  Software  Common  Element  must  be  experienced  in  software  project 
management  and  software  systems  engineering,  integration,  and  test  within  the  context  of  large  com¬ 
plex  software-intensive  systems.  The  manager  responsible  for  the  SEIT  WBS  element,  however, 
usually  has  a  hardware  systems  engineering  background  with  no  direct  software  experience  or  exper¬ 
tise.  Placing  the  software  cross-product  activities  beneath  the  SEIT  WBS  has  historically  resulted  in 
decreased  visibility  for  software,  inappropriate  allocation  of  resources  to  software,  and  incorrect 
evaluation  of  the  importance  of  software  issues  and  risks  until  those  issues  and  risks  have  become 
major  problems.  Additionally,  placing  the  software  cross-product  activities  beneath  the  SEIT  WBS 
has  resulted  in  many  of  these  critically  important  activities  not  being  performed  because  the  responsi¬ 
ble  management  was  not  sufficiently  knowledgeable  to  be  able  to  define  the  activities  needing  to  be 
accomplished  or  lacked  the  experience  and  expertise  necessary  to  understand  the  importance  of  these 
activities.  As  a  result,  frequently  the  software  cross-product  activities  performed  under  SEIT  man¬ 
agement  are  limited  to  chairing  a  software  process  working  group  and  preparing  the  Software  Devel¬ 
opment  Plan. 

For  the  above  reasons  and  from  a  software  risk  management  perspective,  the  optimal  position  for  the 
program-level  Software  Systems  Engineering,  Integration,  and  Test  WBS  Common  Element  is  at 
Level  2  in  the  space  system  WBS  structure,  at  the  same  level  as  the  program-level  SEIT  WBS  Com¬ 
mon  Element.  The  program-level  Software  Systems  Engineering,  Integration,  and  Test  WBS  Com¬ 
mon  Element  should  not  be  subordinate  to  the  program-level  SEIT  WBS  Common  Element.  Simi¬ 
larly,  Software  Common  Elements  at  lower  WBS  levels  should  not  be  subordinate  to  the  lower  level 
SEIT  WBS  Common  Elements,  but  should  be  at  the  same  level  as  their  corresponding  lower  level 
SEIT  WBS  Common  Elements. 
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6.  Software  WBS  Elements  for  the  Early  Acquisition  Phases 


The  standard  space  system  WBS  structure  in  MIL-HDBK-881 A  is  designed  for  the  System  Acquisi¬ 
tion  portion  of  the  acquisition  life  cycle  since  it  elaborates  the  product  hierarchy  down  through  Level 
4.  Per  NSS  03-01 ,  the  System  Acquisition  portion  of  the  acquisition  life  cycle  includes  Phase  B 
(Preliminary  Design),  Phase  C  (Detailed  Design),  and  the  development  portion  of  Phase  D  (Build  and 
Operations). 

In  the  Pre-System  Acquisition  portion  of  the  acquisition  life  cycle,  the  products  are  not  yet  being 
developed,  and  a  full  elaboration  of  the  WBS  structure  for  the  eventual  product  hierarchy  is  not  yet 
needed.  The  Pre-System  Acquisition  portion  of  the  acquisition  life  cycle  includes  Pre-Phase  A  (Con¬ 
cept  Studies)  and  Phase  A  (Concept  Development)  per  NSS  03-0 1 .  During  the  Pre-System  Acquisi¬ 
tion  portion  of  the  acquisition  life  cycle,  critical  decisions  about  system  requirements  and  architecture 
are  made,  and  risk  reduction  efforts  are  undertaken.  It  is  imperative  that  software  be  a  full  partner 
with  hardware  in  these  critical  decisions  and  risk  reduction  efforts  for  new  software-intensive  space 
systems.  It  is  also  imperative  that  software  systems  engineering  and  risk  reduction  be  allocated  its 
own  budget,  separate  from  the  SEIT,  space  segment,  and  ground  segment  budgets. 

During  Pre-Phase  A,  the  software  work  will  focus  on  software  systems  engineering  activities  (e.g., 
software  architecture  trade  studies),  downstream  software  risk  reduction  activities  (e.g.,  prototype 
mission  processing  or  mission  planning  algorithm  development),  and  software  development  planning, 
tracking,  and  controlling  for  software-related  activities  performed  during  this  phase.  Therefore,  at  the 
beginning  of  Pre-Phase  A,  the  principal  software  element  in  the  space  system  WBS  should  be  the 
Level  2  Software  Common  Element  “Software  Systems  Engineering,  Integration,  and  Test.”  How¬ 
ever,  software  development  may  begin  in  certain  areas,  such  as  the  end-to-end  system  simulator  and 
prototype  software  for  high-risk  areas.  So  even  in  Pre-Phase  A,  there  may  be  some  software  product 
development  activities  that  require  lower  level  software  product  development  WBS  elements. 

During  Phase  A,  most  software  work  will  still  be  performed  under  the  Level  2  Software  Common 
Element.  Examples  of  important  cross-product  software  activities  performed  during  this  phase  are 
the  system/segment  requirements  definition  for  software-related  requirements,  system  design  deci¬ 
sions  related  to  software,  development  of  the  top-level  processing  hardware  and  software  architecture, 
software  process  definition  and  software  development  planning  for  the  entire  program,  and  software 
trade  studies  [e.g.,  use  of  Commercial  Off-the-Shelf  (COTS)  and  reuse  software].  As  the  program 
moves  into  and  through  Phase  A,  more  activities  will  be  performed  by  the  segments,  and  the  WBS 
will  need  to  be  elaborated  to  lower  levels  to  reflect  the  evolving  product  structure.  Work  may  also  be 
performed  under  Software  Common  Elements  at  WBS  Level  3  and  possibly  at  Level  4.  In  addition, 
work  will  begin  to  be  performed  under  lower  level  software  product  development  WBS  elements  for 
more  software  items,  especially  those  software  items  considered  mission  critical  or  having  higher 
risk. 
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Ihus,  the  Software  Common  Element  at  WBS  Level  2  is  important  throughout  all  acquisition  phases. 
In  the  beginning,  software  activities  are  principally  performed  under  this  WBS  element.  As  the  pro¬ 
gram  progresses  through  Pre-System  Acquisition  and  into  System  Acquisition,  software  activities  are 
also  performed  under  additional  lower  level  WBS  software  common  elements  and  software  product 
development  elements. 
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7.  Relationship  Between  WBS  Elements  and  Organizational  Structures 


The  WBS  is,  by  definition,  a  hierarchical  structure  used  for  enumerating  and  organizing  all  of  the 
work  on  a  program,  principally  for  the  purpose  of  managing  program  costs.  When  using  1PPD  as  a 
management  philosophy,  the  program  is  organized  into  a  hierarchical  structure  of  IPTs,  with  each  IPT 
being  responsible  for  all  aspects  of  the  development  of  its  assigned  product.  Typically,  the  manager 
of  an  IPT  is  responsible  for  all  work  performed  under  a  particular  WBS  element  and  all  of  its  subor¬ 
dinate  elements  (e.g.,  the  ground  segment  IPT  manager  is  responsible  for  all  work  performed  under 
the  Level  2  Ground  Segment  WBS  element,  including  all  of  its  subordinate  elements).  In  this  way, 
the  costs  for  all  of  the  work  under  a  particular  IPT  can  be  rolled  up  into  a  single  WBS  element,  mak¬ 
ing  overall  cost  management  for  that  IPT  easier. 


For  IPPD,  the  product-development  WBS  elements  and  the  IPTs  are  usually  in  one-to-one  correspon¬ 
dence,  down  to  the  lowest  level  in  the  IPT  structure.  In  addition,  there  should  also  be  an  IPT  respon¬ 
sible  for  each  of  the  WBS  Common  Elements  (with  some  exceptions,  such  as  the  Level  2  WBS  ele¬ 
ment  associated  with  the  cost  of  data  preparation  and  delivery).  Thus,  at  Level  2,  there  should  be  a 
Systems  Engineering,  Integration,  and  Test  IPT  that  is  responsible  for  the  work  under  the  Level  2 
WBS  SEIT  Common  Element.  Similarly,  there  should  be  a  Level  2  IPT  for  Software  Systems  Engi¬ 
neering,  Integration,  and  Test  that  is  responsible  for  the  work  under  the  Level  2  WBS  Software 
Common  Element.  The  recommendation  for  separate  Level  2  IPTs  for  the  SEIT  and  Software  WBS 
Common  Elements  should  not  be  interpreted  to  mean  that  one  IPT  considers  only  hardware  and  the 
other  only  software.  The  Systems  Engineering,  Integration,  and  Test  IPT  must  be  software  cognizant, 
and  the  Software  Systems  Engineering,  Integration,  and  Test  IPT  must  be  hardware  cognizant.  In 
addition,  these  two  IPTs  must  work  closely  together.  There  is  precedence  for  having  a  Level  2  IPT 
responsible  for  the  activities  under  the  Level  2  WBS  Software  Common  Element  (described  in  Sec¬ 
tion  4  above).  During  Pre-Phase  A,  the  Space  Radar  program  established  a  Software  Directorate  (3- 
letter  organization)  that  successfully  carried  out  this  responsibility. 

Shortly  after  IPPD  was  instituted,  the  need  for  integrative  mechanisms  was  recognized  in  order  to 
facilitate  cross-IPT  integration  and  to  coordinate  cross-IPT  actions.  Traditional  examples  of  integra¬ 
tive  mechanisms  are  Interface  Control  Working  Groups  (ICWGs),  Engineering  Review  Boards 
(ERBs),  and  Test  Planning  Working  Groups  (TPWGs).  Most  commonly,  responsibility  for  managing 
these  traditional  integrative  mechanisms  has  been  allocated  to  the  Level  2  SEIT  IPT,  with  the  activi¬ 
ties  associated  with  managing  these  integrative  mechanisms  included  under  the  Level  2  WBS  SEIT 
Common  Element.  While  the  Level  2  SEIT  IPT  has  systems  engineering  products  for  which  it  is 
responsible,  much  of  the  work  of  the  SEIT  IPT  consists  of  managing  integrative  mechanisms  across 
the  space  system’s  product  development  IPTs  and  other  lower  level  SEIT  IPTs. 

Similarly,  while  the  Level  2  Software  Systems  Engineering,  Integration,  and  Test  IPT  has  software 
products  for  which  it  is  responsible,  much  of  the  work  of  this  IPT  consists  of  managing  integrative 
mechanisms  across  the  space  system’s  software  product  organizations  and  other  lower  level  Software 
Systems  Engineering,  Integration,  and  Test  IPTs.  Integrative  mechanisms  must  also  exist  between 
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the  SEIT  IPTs  and  Software  Systems  Engineering,  Integration,  and  Test  IPTs,  both  within  and 
between  levels  of  the  IPT  structure. 

Many  problems  on  space  programs  can  be  attributed  to  inadequate  communication  across  multiple 
IPTs  involving  numerous  organizations,  sometimes  with  wide  geographical  dispersion.  Research  in 
the  effective  application  of  IPPD  has  resulted  in  a  number  of  papers  concerning  effective  integrative 
mechanisms.4  Further  study  needs  to  be  done  to  define  the  most  effective  integrative  mechanisms  for 
both  software  and  systems  engineering  in  the  space  system  domain.  Such  a  study  is  out  of  the  scope 
of  this  report. 


4  See,  for  example,  Tyson  R.  Browning,  “Multi-Team  Integration:  Interdependence  and  Integrative  Mechanisms, 
Proceedings  of  the  Sixth  Annual  International  Symposium  of  INCOSE,  Boston,  7-1 1  July  1996,  pp.  787-794. 


8.  Conclusion 


This  report  has  described  the  various  software  activities  that  must  be  performed  for  space  system 
development  and  has  provided  recommendations  as  to  where  these  activities  belong  in  the  Standard 
Product-Oriented  WBS  structure  for  space  systems.  Development  activities  for  individual  software 
items  will  reside  at  lower  WBS  levels  underneath  the  WBS  elements  for  the  products  in  which  the 
software  items  reside.  There  are,  however,  a  large  number  of  very  important  cross-product  software 
activities  that  must  be  accomplished.  These  activities  belong  in  WBS  Software  Common  Elements  at 
Level  2  and  below.  In  particular,  the  cross-product  activities  of  the  Level  2  WBS  Software  Common 
Element  are  especially  important  for  program  success,  and  should  be  the  responsibility  of  a  Software 
Systems  Engineering,  Integration,  and  Test  Level  2  1PT. 
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Appendix — Recommended  Product-Oriented  WBS 
for  Software-Intensive  Space  Systems 


The  Table  1 A  has  been  taken  from  MIL-HDBK-881 A  (Table  F,  P.  76).  Some  elements  in  Table  F 
from  MIL-HDBK-881  A  have  been  modified,  and  others  have  been  added  to  illustrate  a  more  com¬ 
plete  WBS  structure  for  today’s  software-intensive  space  systems.  These  modified  and  added  ele¬ 
ments  are  shown  in  italics  in  Table  1  A. 


Table  1  A.  Recommended  Product-Oriented  WBS  for  Space  System 


Level  1 

Level  2 

Level  3 

Level  4 

Space  System 

Program  Management 

Systems  Engineering,  Integra¬ 
tion  and  Test  (SEIT) 

End-to-End  System 

Simulator * 

SEIT/PM  and  Other  Common 
Elements5 6 

End-to-End  Simulator  Hardware 
End-to-End  Simulator  Software 

Software  Systems  Engineering, 
Integration  and  Test 

Software  Planning,  Tracking 
and  Controlling7 
Software-Related  Systems 
Engineering,  Integration  and 
Test 7 

Software-Related  Technical 
Reviews  and  Audits7 

Software  Configuration 
Management7 

Software  Quality  Assurance7 

Training 

Training  Subsystem 

SEIT/PM  and  Other  Common 
Elements6 

Training  Subsystem  Hardware 
Training  Subsystem  Software 

Training  Services  and 
Courseware 

Operational  Site  Activation  and 
Operations  Support 

Common  and  Peculiar  Support 
Equipment 

Peculiar  Support  Equipment 
(1...n) 

SEIT/PM  and  Other  Common 

5  Generally,  the  End-to-End  System  Simulator  is  included  under  the  SEIT  Level  2  WBS. 

6  Each  SEIT/PM  and  Other  Common  Elements  WBS  entry  at  levels  3  and  4  in  this  table  must  be  expanded  into  a  list  of 
common  elements  appropriate  to  the  higher  level  WBS  element  to  which  it  is  subordinate.  See  the  Level  2  WBS  Common 
Elements  as  examples. 

7  These  are  examples  of  possible  Level  3  WBS  elements  for  the  Level  2  Software  Common  Element  “Software  Systems 
Engineering,  Integration  and  Test.  See  Section  4  of  this  report  for  an  example  elaboration  of  the  activities  that  would  be 
included  under  each  of  these  Level  3  WBS  elements. 
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Level  1 

Level  2 

Level  3 

Level  4 

Elementsb 

Peculiar  Support  Equipment 
Flardware  (1..n) 

Peculiar  Support  Equipment 

Software  (1  ...n) 

Initial  Spares  and  Repair  Parts 
Data 

Other  Common  Elements,  as 
required 

Space  Vehicle  as 

required) 

SEIT/PM  and  Other  Com¬ 
mon  Elements6 

Software  Systems  Engi¬ 
neering,  Integration  and 

Test 

Spacecraft  Bus 

SEIT/PM  and  Other  Common 
Elements6 

Structures  and  Mechanisms 
Subsystem 

Thermal  Control  Subsystem 

Electrical  Power  Subsystem 

Attitude  Control  Subsystem 
Propulsion  Subsystem 

Telemetry,  Tracking,  and  Com¬ 
mand  Subsystem 

Spacecraft  Bus  Flight  Software 

Spacecraft  Simulator 

Spacecraft  Simulator  Flardware 
Spacecraft  Simulator  Software 

Spacecraft  Flight  Testbed 

Spacecraft  Flight  Testbed 

Hardware 

Spacecraft  Flight  Testbed 

Software 

Spacecraft  Automated  Test 
Equipment  (A  TE) 

Spacecraft  ATE  Hardware 

Spacecraft  ATE  Software 

Communication  /  Payload 

SEIT/PM  and  Other  Common 
Elements6 

Communication  (1  ...n  as  required) 
Payload  (1  ...n  as  required) 
Communication/Payload  Flight 
Software  (1  ...n  as  required) 

Comm/Payload  (1...n) 
Simulator 

Comm/Payload  (1..  .n)  Simulator 
Hardware 

Comm/Payload  (1...n)  Simulator 
Software 

Comm/Payload  (1...n)  Flight 
Testbed 

Comm/Payload  (1...n)  Flight  Test¬ 
bed  Hardware 

Comm/Payload  (1...n)  Flight  Test¬ 
bed  Software 

Comm/Payloa d  (1...n)  ATE 

Comm/Payload  (1...n)  ATE 

Hardware 

Comm/Payload  (1...n)  ATE 

Software 

Booster  Adapter 
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Level  1 


Level  2 

Level  3 

Ground  (1...n  as  required) 

Space  Vehicle  Storage 

Launch  Systems  Integration 
Launch  Operations  &  Mis¬ 
sion  Support 

SEIT/PM  and  Other  Com¬ 
mon  Elements6 

Software  Systems  Engi¬ 
neering,  Integration  and 

Test 

Ground  Terminal 

Subsystems 

Command  and  Control 
Subsystem 

Mission  Management 
Subsystem 

Data  Archive/Storage 
Subsystem 

Mission  Data  Processing 
Subsystem 

Mission  Data  Analysis  and 
Dissemination  Subsystem 

Mission  Infrastructure 
Subsystem 

Collection  Management 

Level  4 


SEIT/PM  and  Other  Common 
Elements6 

Ground  Terminal  Hardware 
Ground  Terminal  Software 


SEIT/PM  and  Other  Common 
Elements6 

Command  and  Control  Subsystem 
Hardware 

Command  and  Control  Subsystem 
Software 


SEIT/PM  and  Other  Common 
Elements6 

Mission  Management  Subsystem 
Hardware 

Mission  Management  Subsystem 
Software 


SEIT/PM  and  Other  Common 
Elements6 

Data  Archive/Storage  Subsystem 
Hardware 

Data  Archive/Storage  Subsystem 
Software 


SEIT/PM  and  Other  Common 
Elements6 

Mission  Data  Processing 
Subsystem  Hardware 
Mission  Data  Processing  Subsys¬ 
tem  Software 


SEIT/PM  and  Other  Common 
Elements6 

Mission  Data  Analysis  and  Dis¬ 
semination  Subsystem  Hardware 
Mission  Data  Analysis  and  Dis¬ 
semination  Subsystem  Software 


SEIT/PM  and  Other  Common 
Elements6 

Mission  Infrastructure  Subsystem 
Hardware 

Mission  Infrastructure  Subsystem 
Software 
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Level  1 

Level  2 

Level  3 

Level  4 

Collection  Management 
Subsystem 

SEIT/PM  and  Other  Common 
Elements6 

Collection  Management  Subsys¬ 
tem  Hardware 

Collection  Management  Subsys¬ 
tem  Software 

Ground  Simulators  (1  ...n) 

SEIT/PM  and  Other  Common 
Elements6 

Ground  Simulator  Hardware  (1.  .n) 
Ground  Simulator  Software  (1  .  .  .n) 

Launch  Vehicle 

26 


THE  AEROSPACE 

CORPORATION 


2350  E.  El  Segundo  Boulevard 
El  Segundo,  California  90245-4691 
U.S.A. 


